Disk Space Allocation

Planning the disk space requirements for the VHS requires knowledge of the number of points (or anticipated number of points) configured to report history, the reporting options enabled for those points (maximum reporting interval, minimum evaluation time, and force evaluation on update), data compression options, the anticipated rate of change, and the retention period for the point values. Disk space allocations should also take VHS Journal Files, "dirty" databases that may be created by VHS Quick Recovery, and VHS Change Queue size into consideration.

By default, the service allocates 10 GB of disk space for history. This is set by the HISTORY_FILE_SIZE_MAX_GB keyword in the VHS configuration file (Vhs.cfg). As your system grows, you can safely increase this allocation to meet your needs. When your system is at a steady state, the file size requirements should stabilize unless reporting options are changed. Before increasing the allocation, be sure to check the amount of available disk space on the server and keep in mind the requirements (both present and future) of other services. Reducing the file size after the service has been in operation, although possible, may result in the loss of data and is not recommended.

As the VHS datastore grows, the VHS will resize the database by the amount set in the VHS_FILE_SIZE_GROW_BY_MB keyword. Note that larger databases tend to perform better with a larger "grow by size" setting.

When the VHS disk space allocation is full, the service screen shows the Value File Size as 100%. Once the VHS is full, if the service receives data for an existing point it will discard the point’s oldest data to make room for the new data. If the service is full and a new point starts reporting data, the service will allocate 1 value block (127 entries) for the point. If additional value blocks have been allocated for new points the Value File Usage may be greater than 100%.

CygNet Software recommends that you use Service Monitoring Service points to monitoring the VHS file. You can monitor the actual file size, the percent full, and rates of change.

Very Large VHS Datastores and File Fragmentation

The VHS uses ESE as its database technology, the same database technology used in Microsoft’s Exchange Server. This database technology allows for very large repository sizes (~5 TB), but the Windows NT File System (NTFS) has some limitations that can cause issues when any one file becomes very large and is experiencing fragmentation. If your production VHS database is larger than 500 GB, it's import to understand that a highly fragmented VHS database file, coupled with a small disk allocation size, can lead to potentially failure.

The following articles from Microsoft provide information about how files are stored within a NTFS volume:

• The Four Stages of NTFS File Growth
• The Four Stages of NTFS File Growth, Part 2

It's important to be aware of the following facts and how they affect large database files such as the VHS history file:

1. NTFS has a limitation on how large the File Attribute List (FAL size) can grow.
2. File fragmentation accelerates with the growth of the Attribute List.
3. Larger files require more Attribute Lists.
4. Once you run out of room for growth on the Attribute List, the database file can grow no further.

What does this failure look like?

The VHS will crash and report the following error:

1.Unknown software exception 40000015

Restarting the VHS will not resolve the issue. The service will restart but will be unable to grow the VHS history file and will return the following error in the log file:

1.EXCEPTION(S): JetUpdate(nobookmark): JET_errDiskIO, Disk IO error (class CEseError) Handled: VhsHistoryReceiver.cpp

Possible Solutions

Unfortunately, there isn’t a SVCMON point that can provide insight into this fragmentation problem. You can use the Microsoft Contig.exe utility to analyze fragmentation and help determine the root cause of the issue. Run contig with the "-a" switch and analyze the fragmentation count of the file. If contig reports ~1.5 million fragments then you are dangerously close to the failure condition described above.

There are a couple options you can take to avoid this issue:

1. Maintain a smaller VHS. Use thinning mechanisms either on point update, or as part of a thinning rule.
2. Adjust your NTFS volume to allow for more data to be stored in the sector sizes.

If you choose option number two, be aware that you will need to do the following:

1. Copy all files off the affected drive.
2. Reformat the affected volume to increase the sector size.
3. Copy all files back on the newly formatted drive.

Copy and pasting files from one volume to another will also make them contiguous, so any fragmentation of the file will be addressed as part of that operation.